Serverless Architecture

Serverless architecture is a cloud-native design pattern where applications are built using Function-as-a-Service (FaaS) and Backend-as-a-Service (BaaS) components. The term "serverless" doesn't mean there are no servers — rather, it means that developers don’t manage the servers. The cloud provider automatically provisions, scales, and manages infrastructure.

Characteristics of Serverless Architecture

Feature	Description
Event-driven	Functions execute in response to events (e.g., HTTP request, file upload).
Auto-scaling	Automatically scales up/down based on load.
No server management	Abstracted infrastructure — no provisioning, patching, or maintenance.
Pay-per-use	Billed only for the time your function runs (e.g., per 100ms).
Stateless	Functions don’t persist data between executions; external storage is used.

Components in Serverless System Design

1. Frontend/UI

   • Static frontend hosted on services like Amazon S3, Netlify, or Vercel.
   • Communicates with APIs via HTTPS.

2. API Gateway

   • Entry point for all HTTP requests (e.g., AWS API Gateway).
   • Routes requests to the appropriate function.

3. Function-as-a-Service (FaaS)

   • Each function is a small unit of business logic (e.g., AWS Lambda, Azure Functions).
   • Executes on demand in isolated containers.

4. Backend-as-a-Service (BaaS)

   • Pre-built services like:
     • Authentication (e.g., Firebase Auth, Amazon Cognito)
     • Storage (e.g., S3, Firebase Storage)
     • Database (e.g., DynamoDB, Firebase Realtime DB)

5. Database

   • Serverless-friendly databases:
   • NoSQL (e.g., DynamoDB, Firestore)
   • Serverless SQL (e.g., Aurora Serverless, PlanetScale)

Example of Serverless Image Processing

Build a web app where users upload images, and the system creates thumbnails.

User → [Frontend (React/HTML)]
     → [API Gateway (AWS API Gateway)]
     → [Upload Endpoint (Lambda Function)]
         → [Store in S3]
         → [Trigger Event: S3 Upload]
             → [Resize Function (Lambda)]
                 → [Save Thumbnail to S3]

Workflow Explanation

1. Frontend

   • User uploads image via a web form.
   • Sends image to an API Gateway endpoint.

2. API Gateway

   • Routes the request to the uploadImage Lambda function.

3. Upload Function (Lambda)

   • Stores the image in an S3 bucket.

4. S3 Bucket Event Trigger

   • When a new file is uploaded, it triggers another Lambda function (resizeImage).

5. Resize Function (Lambda)

   • Reads the uploaded image.
   • Resizes it to thumbnail size.
   • Stores it in a different S3 bucket (or folder).

Advantages

• Scalability: Automatically handles hundreds or millions of uploads.
• Cost-Effective: Pay only when users upload images.
• Rapid Development: Focus on core logic, not infrastructure.
• Resilience: Built-in fault tolerance and retries in services like AWS Lambda

Challenges of Serverless Image Processing

Challenge	Description
Cold starts	Functions may experience delay if inactive for a while.
Vendor lock-in	Tied to a cloud provider's ecosystem.
Stateless nature	Requires external systems for session management or persistent state.
Debugging complexity	Logs are distributed across functions — harder to trace flows.

When to Use Serverless Architecture

• Lightweight microservices or APIs.
• Event-driven workflows (e.g., file processing, notifications).
• Real-time data processing (e.g., chat apps, IoT ingestion).
• Startups or MVPs that need fast deployment and low ops.

When NOT to Use

• Long-running tasks or heavy compute workloads.
• Applications requiring very low latency.
• Complex stateful workflows.